Remarks 

The above amendments to the above-captioned application along with the following 
remarks are being submitted as a full and complete response to the Office Action dated 
August 13, 2009 (U.S. Patent Office Paper No. 20090806). In view of the above 
amendments and the following remarks, the Examiner is respectfully requested to give due 
reconsideration to this application, to indicate the allowability of the claims, and to pass this 
case to issue. 

Status of the Claims 

As outlined above, claims 16 and 17 stand for consideration in this application, 
wherein claims 1, 3-5, and 7-15 are being canceled without prejudice or disclaimer, and 
wherein claims 16 and 17 are being newly added. 

All amendments to the application are fully supported therein. For example, the 
amendments to the claims are supported by paragraphs [0055] - [0057] of the present 
application as originally filed, as well as by Figures 8 and 9. Applicants hereby submit that 
no new matter is being introduced into the application through the submission of this 
response. 

Prior Art Rejections 

The Examiner rejected claims 1, 3, 5, 7-8, 10 and 15 under 35 U.S.C. §103(a) as 
being unpatentable over Takahashi (U.S. Patent Application Pub. No. 2004/0008664) in view 
of Firestone (U.S. Patent No. 6,965,646). The Examiner rejected claims 4, 9, 1 1-14 under 35 
U.S.C. § 103(a) as being unpatentable over Takahashi in view of Firestone, and in further 
view of the Background section of the present application ("the background art"). Applicants 
have reviewed the above-noted rejections, and hereby respectfully traverse. 

A proper obviousness rejection requires establishing that the prior art references, 
when combined, teach or suggest all of the claim limitations. MPEP §2143. As outlined 
above, claims l\ 3-5, and 7-15 are being canceled, wherein claims 16 and 17 are being newly 
added and remain of record. Accordingly, Applicants respectfully submit that Takahashi, 
either alone or in combination with Firestone and/or the background art, fails to teach, 
suggest, or disclose each and every limitation of claims 16 and 17. For example, none of the 
cited references teach or suggest that "the data delivery server includes a search packet 
detecting module for detecting a search packet sent from the first mobile terminal and 
received by the data delivery server" as required by independent claim 16. Rather, Takahashi 



contrastingly describes various examples of the operation in a packet communication system 
of a correspondent node (CN) transmitting IP packets to a mobile node (MN) in which the 
MN "collects information on the path from the CN and announces the Path MTU based on 
the collected information to the CN. More specifically, according to the present invention, 
the [N4N] collects information about entry points of multiple tunnels (particularly, 
MAPs) existing on the path from the CN, calculates the Path MTU on the basis of the 
information about the entry points of multiple tunnels thus collected, and announces the Path 
MTU to the CN." (Para. [0094]) (emphasis added). Takahashi further provides that "[o]n the 
occasion of transmitting data, the CN 2 discovers a Path MTU of a path routed to a 
destination node" and, while the CN is transmitting data to the MN, "when receiving a BU 
[Binding Update] message with an ICMPPTB message [Internet Control Message 
Protocol Packet Too Big message] from the mobile node, the CN 2 updates the Path MTU on 
the basis of the Path MTU indicated by the ICMPPTB message. (Paras. [0099] - [0100]) 
(emphasis added). 

Takahashi also explains that "[w]hen the MN 3 moves during reception of data to 
update the path to another, it collects information about MAPs (entry points of multiple 
tunnels) existing on the new path after the update and announces to the correspondent (CN 
2) the Path MTU calculated based on the number of MAPs thus collected. For 
implementing it, the MN 3 is provided with... processor 3d... that is comprised of multiple 
tunnel entry-point advertisement receiving function 3e, Path MTU discovery execution 
determining function 3f, Path MTU calculating function 3g, and Path MTU announcing 
function 3h," (Para. [0112]) (emphasis added), "The Path MTU announcing function 3h 
adds an ICMPPTB message to a BU message and lets the transceiver 3b send the BU 
message through antenna 3a to CN 2." (Para. [0118]). A correspondent node transmitting 
data to a mobile that receives a binding update message announcing a Path MTU from a 
mobile node, as described in Takahashi, is clearly not a data delivery server that includes a 
search packet detecting module for detecting a search packet sent from a mobile terminal 
and received by the data delivery server, as required by claim 1. 

Moreover, Firestone fails to include any mention or suggestion of any data delivery 
server that includes a search packet detecting module for detecting a search packet sent from 
a mobile terminal and received by the data delivery server as required by claim 16. Finally, 
the background art simply describes "sending a ping packet of a given length to another host 
thereby determine the value of the MTU in dependence on the response behavior." (Para. 
[0005]). A host merely mentioned as a host to which a ping packet is sent, as provided in the 



background art, is clearly not a data delivery server that includes a search packet detecting 
module for detecting a search packet sent from a mobile terminal and received by the data 
delivery server, as required by claim 1. Accordingly, Takahashi, either alone or in 
combination with Firestone and/or the background art, fails to teach, suggest, or disclose that 
"the data delivery server includes a search packet detecting module for detecting a search 
packet sent from the first mobile terminal and received by the data delivery server" as 
required by claim 16. For this reason alone, claim 16 is patentable over the cited prior art 
references. 

As another example, none of the cited references teach or suggest that "the data 
delivery server includes a search packet detecting module,.. for determining a maximum size 
for a single IP packet to be sent to the first mobile terminal based upon a packet size of the 
detected search packet" as required by claim 16. Rather, as discussed above, Takahashi 
contrastingly provides that "[o]n the occasion of transmitting data, the CN 2 discovers a 
Path MTU of a path routed to a destination node" and, while the CN is transmitting data to 
the MN, "when receiving a BU [Binding Update] message with an ICMPPTB message 
[Internet Control Message Protocol Packet Too Big message] from the mobile node, the CN 2 
updates the Path MTU on the basis of the Path MTU indicated by the ICMPPTB message. 
(Paras. |0099] - [0100]) (emphasis added). 

Takahashi, in further contrast to claim 16, explains that " the MN 3 is provided 
with... processor 3d... that is comprised of multiple tunnel entry-point advertisement 
receiving function 3e, Path MTU discovery execution determining function 3f, Path MTU 
calculating function 3g . and Path MTU announcing function 3h" (para. [0112]), and "the 
Path MTU calculating function 3g calculates the Path MTU according to a calculation 
equation of (the Path MTU of the path before the update - the size of the IP header 
added upon one encapsulation at MAP x (the number of MAPs selected by the multiple 
tunnel entry-point advertisement receiving function 3e - the number of MAPs existing 
on the path before the update)). (Para. [0117]) (emphasis added). Takahashi then provides 
that "the MN 3 generates a BU message with an ICMPPTB message indicating the calculated 
Path MTU, sends the BU message to the CN 2, and terminates the processing (SI3)....When 
the CN 2 receives the BU message with the ICMPPTB message from the MN 3, it updates 
the preserved Path MTU to the Path MTU indicated in the ICMPPTB message." (Para. 
[0128] - [0129]) (emphasis added). A correspondent node that sets a Path MTU by 
discovering the Path MTU to a mobile node at the outset of transmitting data to the mobile 
node or by receiving a binding update message announcing an updated Path MTU from the 



mobile node when the mobile node moves, where the mobile calculated the Path MTU 
according to the Path MTU of the path before the update, the size of the IP header added 
upon one encapsulation at MAP, the number of MAPs selected by the multiple tunnel entry- 
point advertisement receiving function 3e, and the number of MAPs existing on the path 
before the update, as described in Takahashi, is very clearly not a data delivery server that 
includes a search packet detecting module for determining a maximum size for a single 
IP packet to be sent to a mobile terminal based upon a packet size of the detected search 
packet , as required by claim 16. 

Moreover, Firestone simply provides that a "packetizer 104 must encapsulate the file 
in network packets using a network packetization protocol . The protocol, or standard, will 
designate a number of rules for packetization of the data for the network ." (Col. 1, 11. 41- 
44) (emphasis added). Firestone further describes a system for transmitting MPEG data from 
an MPEG file onto a network in which a "segmenter 222 preferably employs a Maximum 
Transmission Unit (MTU) length of the packet defined for the network onto which the 
data is to be transmitted." (Col. 7, 11. 58-60) (emphasis added). A segmenter that simply sets 
a packet length based upon a network packetization protocol defined by a network, as 
described in Firestone, is very clearly not a data delivery server that includes a search packet 
detecting module for determining a maximum size for a single IP packet to be sent to a 
mobile terminal based upon a packet size of the detected search packet as required by 
claim 16. Likewise, the background art fails to include any mention or suggestion that "the 
data delivery server includes a search packet detecting module... for determining a maximum 
size for a single IP packet to be sent to the first mobile terminal based upon a packet size of 
the detected search packet" as required by independent claim 16. For this reason alone, claim 
16 is patentable over the cited prior art references. 

For at least these reasons. Applicants respectfully submit that Takahashi, either alone 
or in combination with Firestone and/or the background krt, fails to teach, disclose, or suggest 
each and every limitation of claim 16 and, therefore, that claim 16 is now in condition for 
allowance. Where an independent claim is nonobvious under 35 U.S.C. §103, then any claim 
depending therefrom is nonobvious. In re Fine, 5 U.P.S.Q.2d 1596, 1598 (Fed. Cir. 1988). 
Because claim 17 depends directly from claim 16, Applicants respectfully submit that 
Takahashi, either alone or in combination with Firestone and/or the background art, does not 
render obvious claim 17 for at least the reasons set for the above that it does not render 
obvious claim 17, and that claim 17 is also now in condition for allowance. 



Therefore, Applicants respectively submit that the present invention as claimed is 
distinguishable and thereby allowable over the prior art of record. 

Conclusion 

In view of all the above, Applicants respectfully submit that certain clear and distinct 
'^differences as discussed exist between the present invention as now claimed and the prior art 
references upon which the rejections in the Office Action rely. These differences are more 
than sufficient that the present invention as now claimed would not have been anticipated nor 
rendered obvious given the prior art. Rather, the present invention as a whole is 
distinguishable, and therel^y allowable over the prior art. 

Favorable reconsideration of this application as amended is respectfully solicited. 
Should there be any outstanding issues requiring discussion that would further the 
prosecution and allowance of the above-captioned application, the Examiner is invited to 
contact the Applicants' undersigned representative at the address and phone number indicated 
below. 
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